-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more print schema ordering options #2042
Add more print schema ordering options #2042
Conversation
👷 Deploy request for apollo-federation-docs pending review.Visit the deploys page to approve it
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
howdy @id-ilych and thanks for the PR! Would you mind updating with the latest from
Yes to both of these! |
901b1f1
to
92facb1
Compare
Thanks @benweatherman. I did as you suggested. |
@id-ilych thanks for the updates! for some reason, our CI isn't running fully on your commits. Have you signed the apollo CLA previously? is there any chance you're using CircleCI's follow feature to follow your fork of the code? |
Hey @benweatherman 👋 I have signed CLA on 23 Jun 2021. But I did so again, just in case. Regarding the CircleCI, I did not do any configuration. Should I? |
No need to do any special config. Following the fork in CircleCI was the internal working theory as to why the tests weren't running. Will dig into this a bit more. |
I'll admit that I'm on the fence about changing the current output of composition. I'm totally on board about adding the option to order everything, and in principle I don't disagree that ordering everything can be desirable. But changing the order has very visible consequences, and doing so "by default" might lead to some painful/scary initial upgrades. Such change to the default could be something we do in a major release, but I think we trying hard to not do one of those any time soon, and I'm less confortable doing it in a minor release (but open to other opinions). That said, even if we keep the current default, I'm again very on board with adding ordering options. That does imply adding some option to the |
Hello @pcmanus 👋 What do you think about adding a separate method |
First, sorry for the delay in my answers here. Since my last comment, I realised that things weren't exactly as I though they were around this issue. Let me explain. I "though" that the ordering composition is using in federation 2 (which orders types/directives but fields within types) was the same one that in federation 1 and the one composition had always used. Which is why I was a bit worried about changing it now. Fwiw, that's why I initially didn't understood why you said that "on major upgrades creates quite chaotic diff". Anyway, the reason I held that belief is that I implemented the order for federation 2 and when I did so, I very much was careful to match federation 1 behaviour (I probably wouldn't have sorted only some of the elements otherwise). But apparently there was a communication issue somewhere a year ago, because I missed that #824 was committed to federation 1 to change the ordering so everything gets sorted. This was unfortunately done after the work on federation 2 had started, and I never realised the behaviour had changed in federation 1. Tl;dr, the fact that the ordering changed in the major upgrade between federation 1 and federation 2 is very much an oversight/accident. Not sure how that could have slipped all this time but well ... Anyway, this does change a bit my position here. Because:
So I think my new preferred position here is to decide what ordering we actually want long term (at least by default), and switch to that even if it mean one more change of ordering, but then make sure we're better at keeping that consistent moving forward. Long story short, maybe we just get back to your original suggestion @id-ilych after all, but I'd like to consult a few people that may opinions on this before completely decided here.
Whatever we end up deciding of the default, I'm totally ok with adding more methods that implement various option in the code, so +1 on that part. |
Hello @pcmanus 👋 Any updates on that? |
Hello @benweatherman @pcmanus 👋 A friendly reminder about pending PR. |
Hello @benweatherman @pcmanus 👋 A friendly reminder about pending PR. |
howdy @id-ilych! Unfortunately I no longer have the commit-bit privileges for this repo, so someone within the apollo team will need to weigh in on getting this merged. From what I recall before I left: This is a good change, to be sure. I imagine the apollo team is wrestling with which version in which to release this type of change. It's valuable, but could cause a lot of downstream headaches looking at schema diffs that might only be reordering things. @jeffjakub might also be able to help with this |
Hello @jeffjakub 👋 Can you please take a look at clarify the status? What needs to be done from my side to get this merged? This PR is stuck for 5 months already :( |
I'm very sorry on the progress on this issue. I certainly understand that this is frustrating. To be transparent, I've been having a bit of analysis paralysis on the question of whether we should change the default composition ordering, and if yes, to what. I was hoping to get some larger conversation going on that question to gather some consensus, but didn't got much engagement so far, either because it's not very top of mind for most folks or because the status quo is good enough (but I'll admit too that I have had other priorities myself and I haven't pushed that much). That said, I do realise that the original ask was only to add more options in the code, and not so much about changing the default for composition, and it's entirely on me for distracting from that original purpose. Anyway, I'm still iffy about changing the default ordering of composition at the moment (until some greater consensus emerges about that question), but maybe we can just go back to your earlier suggestions of:
If the patch is updated to do so, with no change to the default behaviour, then I'll commit to getting it in quickly. Again, my apologies for my poor handling of this issue. |
b056522
to
b5f3566
Compare
🦋 Changeset detectedLatest commit: d25fa15 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
b5f3566
to
bcd7a07
Compare
composition-js/src/compose.ts
Outdated
@@ -30,7 +31,15 @@ export interface CompositionSuccess { | |||
errors?: undefined; | |||
} | |||
|
|||
export function compose(subgraphs: Subgraphs): CompositionResult { | |||
export interface ComposeOptions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to call it CompositionOptions
but this name is already exported from merge
:\
I decided not to rename the existing interface to use it for the new thing to avoid breaking somebody's code in a confusing way: same name, totally different usage and meaning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. As the TODO on CompositionOptions
in merge
kind of suggests, the idea was to eventually move the version from merge
into compose
instead of having 2 different ones. So I'd prefer doing this: move the CompositionOptions
to compose.ts
, use it here, and pass it down to mergeSubgraphs
.
Hey @pcmanus 👋 Please check if that's what you meant. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this looks great. I left a small comment regarding ComposeOptions
, and we'll need to rollback the changelog manual edits, but happy to commit after that (and happy to deal with those minor "administrative" details myself if you prefer, just let me know)
composition-js/src/compose.ts
Outdated
@@ -30,7 +31,15 @@ export interface CompositionSuccess { | |||
errors?: undefined; | |||
} | |||
|
|||
export function compose(subgraphs: Subgraphs): CompositionResult { | |||
export interface ComposeOptions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. As the TODO on CompositionOptions
in merge
kind of suggests, the idea was to eventually move the version from merge
into compose
instead of having 2 different ones. So I'd prefer doing this: move the CompositionOptions
to compose.ts
, use it here, and pass it down to mergeSubgraphs
.
composition-js/CHANGELOG.md
Outdated
@@ -1,5 +1,7 @@ | |||
# CHANGELOG for `@apollo/composition` | |||
|
|||
- `compose` and `composeServices` now take optional `ComposeOptions` to customize (at the moment, only `sdlPrintOptions` is supported) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're not editing changelogs manually anymore, we use changeset instead. You can try using npx changeset add
yourself, or I can do it for you. But we'll want to remove the manual edits as they'll conflict with that new process.
Hello @pcmanus 👋 I am not sure I fully got your idea about options. Would you mind finishing it on your own to avoid communication overhead? |
aefcba4
to
fb40f95
Compare
This reverts commit 62581900cc66b4542457695a9246a9fd48e990e9.
fb40f95
to
f9fc352
Compare
f9fc352
to
3f82ecb
Compare
Of course. I've pushed a few commits to the branch (and took the liberty to rebase on @id-ilych: I'll let you have a quick look to make sure those changes work for you. I'll merge if that's that case. |
This reverts commit eb27b07.
@pcmanus Great! Thank you :) |
Hello 👋
I noticed that
printSchema
only have options to order type and directives definitions. But smaller elements like fields, and types in unions have unspecified order which on major upgrades creates quite chaotic diff in the dumped.graphql
file.I added options for sub elements so that it is more stable.
I also added default
localeCompare
-based implementations toorderPrintedDefinitions
helper and updated affected tests.My main two concerns:
orderPrintedDefinitions
to give more stable output?print.ts
file) considering that update of theorderPrintedDefinitions
is observable in other tests?